发完版本后 FB 能进，native 卡 97%
1、手动下载7.2.4 版本的 game.js,assets-manifest查看其中的 commonVersion，确认为 7.2.4；资源版本无误；
2、经查 ios日志发现 game.js 的md5 校验失败：
md5 check failed:Download md5 check failed for file path: /var/mobile/Containers/Data/Application/9623507E-6323-489C-836A-B281E6647229/Documents/Documents_temp/game.js, exepected: 4d00df2c99aa6c53a3b304be0155f084, but got: 3d6cd067de196f6303899d4efab586ee
对比：exepected: 4d00df2c99aa6c53a3b304be0155f084与 7.24 版本manifest 文件记录的md5 一致，
说明 manifest 文件同步成功、且下载成功；
3、手动下载 7.2.4 版本的game.js，本地获取该文件 md5 值为3d6cd067de196f6303899d4efab586ee，与设备下载到本地的game.js的 md5 一致；
说明 7.24 版本的game.js文件下载成功，但上传到 cdn 的 game.js 文件出现了问题；
4、继续排查上传前的 game.js 文件，无异常、与 manifest 记录一致；
5、至此，
7.2.4上传前版本正常；上传后menifest 文件cdn 同步正常、设备下载正常；
怀疑上传过程异常，导致 game.js 出现字节损失；
但查看了上传日志无异常，查证rsync稳定性后，发现上传过程出现问题的可能性不大；
资料证明：
使用 rsync 命令进行远程文件同步时，理论上文件数据不会出现字节丢失的情况，因为 rsync 是为可靠、准确的数据传输而设计的。
rsync 通过以下机制来确保数据的完整性：
- 校验和检测：
rsync使用校验和（checksums）的方式来比较源文件和目标文件，以确保文件完整性。它不仅比较文件的大小和修改时间，还会在必要时生成文件块的校验和，确保每个文件块都被正确地传输。 - 传输校验：在数据传输过程中，
rsync会进行多次校验，例如，利用 CRC（循环冗余校验）等算法来确保数据在网络传输中的完整性。 - 错误处理和重试机制：如果传输过程中发生错误或丢包，
rsync有内置的错误处理和重试机制，以确保最终的数据是一致的。
然而，尽管rsync 本身非常可靠，外界因素（如网络不稳定、硬件故障、磁盘错误等）还是有可能导致数据传输出现问题。在实际运用中，尤其是涉及重要数据的同步时，建议采取以下措施来进一步确保数据的完整性：
- 使用
-c选项：这个选项强制rsync对文件内容进行校验和比较，而不仅仅是文件的大小和修改时间。
rsync -avz -c user@remote_host:/path/to/source /path/to/destination
- 启用校验和传输：使用
--checksum或-ci选项可以确保文件块的传输使用校验和。
rsync --checksum -avz user@remote_host:/path/to/source /path/to/destination
- 日志和验证：执行完毕后可以查看
rsync的详细日志，确保一切文件都被正确同步。此外，可以运行后续的脚本进行文件的二次校验，比如对比源和目标文件的 MD5 或 SHA 校验和。
总的来说，正确使用 rsync 的选项和功能，结合一些外部校验手段，可以非常可靠地同步文件而不丢失字节。
6、重新发版后解决问题，继续分析原因，对比打包机提交的 game.js 文件字节数，发现并未发生改变，怀疑大概率是文件上传到资源服务器后发生变化；
7、从 cdn下载对比7.2.4和 7.2.5 game.js字节大小，发现 7.2.4 多了一个字节；
8、使用UtralCompare 对比，确认行尾多了一个换行符（0A-ASCII:LF）
结论、分析可能的原因：
文件编码问题：不同操作系统或编辑器处理文件编码的方式可能不同，特别是换行符（例如，Unix/Linux 使用
LF，Windows 使用CRLF）。
a.我们是 mac 开发、mac 打包机上传、linux 服务器，所以可以排除文件编码格式问题；【排除】文件传输过程中被修改：确保在传输过程中没有其他进程或脚本修改文件。
这个不可能，上传期间特意留意了，没有其他 jenkins 管道在跑，上传后检查 upload 日志无异常，对比两次上传后打包机提交日志记录的文件大小一致；【排除】Shell 特性：在某些情况下，使用命令行工具可能会意外地在输出中添加换行符。
a、可能性不大，因为我们对上传后编辑器行为：某些文本编辑器在保存文件时会自动添加一个换行符。
最大的可能性：在检查版本号的时候，操作 vim无意中做了 wq 操作，保存一个空行；
经后端确认后，vim 确有一次空白符变更；原理：
在 Vim 文本编辑器中，当你使用:wq命令保存并退出文件时，Vim 通常会在文件末尾添加一个换行符。这是因为 Unix 传统和POSIX标准规定，文本文件应该以一个换行符结尾。具体来说，这是为了保证在使用一些标准的Unix工具处理文件时不会出现意外行为。例如，在使用
cat命令显示文件内容时，如果文件末尾没有换行符，提示符会紧接着文件最后一行的内容显示，这看起来会有些混乱。如果你不希望Vim在文件末尾添加换行符，你可以修改 Vim 的配置来避免这种行为。例如，设置
noeol（no end-of-line）选项：:set noeol
但请注意，这种做法可能会在某些情况下导致兼容性问题或意想不到的行为。
如果你想永久修改这一设置，可以在你的 Vim 配置文件（通常是 `~/.vimrc` 或 `~/.vim/vimrc`）中添加：
set noeol
然而，还是建议遵循默认的Unix文本文件规范，确保文件在保存时以换行符结尾，以保持最大兼容性。
诱因：上传速度异常，传完后安全起见增加了人为审查版本号的步骤；
解决方案：
1、以后检查 cdn 上的文件，务必不能使用 wq（写入保存）；
2、后续出现 卡97%的问题，先对比检查cdn 上 game.js 的文件大小、md5 值；
**3、检查 native 日志时：不要去看 android 日志，直接通过 xcode 连接ios 设备，去查文件校验失败的日志，确定出问题的文件；（**我们只有 ios 的 native 层有明确的文件 md5 校验日志）
事故整改方案：
20240613 Slots发版事故整改方案：
一、事故原因：上传资源时，网络环境不稳定，上传时间过长，上传资源完成后，在对资源进行手动操作检查时不合规范，误操作改写了资源文件，导致文件大小和签名发生变化，致使客户端下载检查时出现校验失败的报错。
二、事故分析：网络环境不稳定是不可控因素，为了确保上传资源的一致性，对资源文件进行检查应该是自动化的基本操作，不应手动进行，以规避风险。原有的自动发布资源的脚本未能覆盖到这个问题，需要进行整改。
三、整改方案：
1、完善打包机上传资源的脚本：
1）上传资源时，应能进行续传，避免网络环境不稳定导致的上传失败；
2）上传资源完成后，应自动进行资源服资源文件进行校验，输出资源服文件的MD5、大小、版本号、修改时间，并与打包机本地的资源文件的MD5进行自动比对，确保资源文件上传的完整性、一致性；
2、完善资源服推送资源的脚本：
1）应确认上传资源文件的完整、一致后，才能推送资源
2）推送资源后，应对资源的CDN链接再自动进行回下，确保每个资源在CDN都能访问到，且资源文件的MD5、大小与资源服的一致；